Czesc Macieju,

sorry for the late reply and thanks for the contribution!

Could you please update README.MD, the section "Mapping customization" with the new keywords?

You can freely use C++17 and [[nodiscard]] instead of Q_REQUIRED_RESULT. The reason for Q_REQUIRED_RESULT was that I had not decided for C++17 yet in one of the earlier QtOrm prototypes.

The NOT_NULL addition is a very useful one but I have a conceptual concern about the cascading.

The reason why I haven't had the foreign key support, especially with cascading, is that the entity cache in the OR-mapper has to be updated as well on the cascade action. Imagine you have the following:

| Provinces                | 
|--------------------------|
| id    |  name            |
|-------|------------------|
| 4     |  Upper Austria   |
|-------|------------------|

| Towns                                 |  
|---------------------------------------|
| id      |  province_id       |  name  |
|---------|--------------------|--------|
| 1       |  4                 |  Linz  |

Now, I read all provinces and towns in the OR-Mapper, and both class instances are created as C++ objects and cached inside the OR mapper in QOrmEntityInstanceCache. And then I execute from<Province>().filter(Q_ORM_CLASS_PROPERTY(name) == "Linz").remove(). The problem here is that we do not know which rows are actually removed from the database, and which referenced entities are affected.

To deal with the first part, I had a prototype implementation of QOrmSqliteProvider::remove performing a helper SELECT id query with the same filter as the remove to find out the cache instances to clean up, but then I dropped it for some reason.

Then I mitigated the problem at least for SQLite > 3.35, because there is a RETURNING clause which is used in QOrmSqliteProvider::remove() to cleanup the cache of Provinces.

The second part of the problem is that we have to find out which entities are referenced by the removed ones and purge them from cache as well. Without the cascading it is the programmer's job to cleanup the referenced Towns before even executing the remove query. Now with cascading it becomes even trickier, and probably requires the secondary SELECT again.

If the OR mapper already does the cascading to clean up its cache, then ON DELETE in the FK definition becomes unneccessary:

• if the OR mapper works correctly, it would do nothing, because the referenced rows would be removed by the OR mapper
• if the OR mapper does not work correctly and skips some of the references, then ON DELETE CASCADE would "silently" remove the referenced rows from the database, and the OR mapper state would become inconsistent. In this case I would rather prefer a foreign key violation error from the database.

What are your thoughts on this?

Cheers & dzieki bardzo

Cześć :) Sorry for the late response too, I was sure I checked here and somehow missed it.

That makes perfect sense, I completely missed the issue (good thing you caught it instead of me finding out after using it 😅 ). Cascade at DB level doesn't make much sense, I'll remove it.

ORM-level cascade would be rather hard to fit with the current API, because remove returns the deleted entities. Technically easy to solve with indirection, but then the programmer would have to expect it.

I think foreign keys for data integrity would still be good though, right?

Ok, @dpurgin I've updated the changes. In the meantime I needed UNIQUE constraints too and found two escape issues - happy to split off into another one if you want to keep this PR smaller.

NOT_NULL could be supported for ALTER TABLE (Append schema mode) but that would require also supporting DEFAULT so for now I just mentioned in the README that this won't work.

EDIT: sorry for drafting again, looks like I messed up a rebase

Thanks for your work! I've tested it with other projects and it looks good!